Closes #13592

This PR implements Automatic Engagement Numbering to provide readable, sequential IDs (e.g., ENG-001) alongside the internal database ID.

1. Feature: Custom Engagement ID

• Backend Logic: Implemented as a read-only @property on the Engagement model. It dynamically formats the existing Primary Key (PK) into a string (e.g., ID 5 -> ENG-005).
• UI Updates: The new ID is now visible in:
  • Engagement List, Engagement Detail Header, Product Dashboard snippet views.

• ID Persistence (Deletion Logic): IDs are permanent once generated. If an engagement is deleted (e.g., if ENG-005 is deleted, the next is ENG-006). I maintained this behavior because implementing ID reuse would require database schema changes (migrations) to manage a complex custom counter. The current approach relies on standard non-changeable unique identifiers, which is safer and keeps this PR migration-free.

3. Limitations & Future Work

• The ID format (ENG-{id:03d}) is currently hardcoded in models.py. Future enhancements could move this to System Settings and enable users to change the ID format (01) or (ENG-{id:02d}) etc.
• The property is display-only and not currently indexed for global search.

Test results

I have manually verified the stability and rendering of the changes:

• UI Verification: Confirmed that the ENG-XXX ID appears in the list columns and detail headers.
• Data Integrity: Verified that "Active", "Mitigated", and "Duplicate" counts in view_eng.html render as integers and not raw template code.
• Flow Testing: Verified that deleting an engagement correctly redirects to the Product page without error.

Documentation

• (UI)